Cream of the Crop 1/Cream of the Crop 1.iso/PROGRAM/TP011093.ARJ/01-10-93.TPC

Text File | 1993-01-10 | 49KB | 1,364 lines

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-04-93 00:17:00
From       Dj Murdoch
To         All
Subject    TRASH.ZIP:  a program to detect and fix

 Borland Pascal 7 introduced 32 bit arithmetic for longints, which gives a perform
nce boost over 16 bit arithmetic.  Unfortunately, it's not safe on some PCs:
those running software that trashes the extended registers.

The best fix for this would be to replace that buggy software, but that's
not an option in most cases.  An alternative would be to install a TSR that
saved and restored the trashed registers, but to do that, you really need
to the details of which registers get trashed and by what.

I've just put together a package called TRASH.ZIP, which does the detection
and general purpose fixes for the register trashing.  I've sent it out on
PDN and to garbo.uwasa.fi on Internet.  It should show up somewhere near you soon.


BTW, even if you're not particularly worried about the trashed registers,
you might want to take a look.  I used a number of tricks to write a TSR that
hooks 16 different interrupts and counts 9 different kinds of event on each
interrupt, all in BP, and with a memory footprint when resident of 640 bytes.
 (It uses a lot of inline assembler, but no external assembler.  Who needs
one?  :-)

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/05  21:57:51

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-04-93 08:27:00
From       Dj Murdoch
To         John Giesbrecht
Subject    Re: TP 7.0

  JG> Dj Murdoch (1:249/99.5) wrote to Paul Campisi on <03 Jan 08:34> :

 DM> "/F16384" tells BP to ask for a 16384K (i.e. 16 Meg) swap file.

 JG> I'm embarassed to admit that I can't find it, but there's
 JG> no other way: where, oh where, is this documented?

User's Guide, p. 37.  There's no documentation on how to get a swap file for
your own program (though there might be in the Open Architecture book), but
Kim Kokkonen sent me this little unit.  He didn't write it; it came from someone
at Borland.

 unit RTMSwap;

 interface

 const
   rtmOK          = $0;
   rtmNoMemory    = $1;
   rtmFileIOError = $22;

 function MemInitSwapFile(FileName: PChar; FileSize: Longint): Integer;
   {  Opens a swapfile of the specified size.  If a swapfile
      already exists, and the new size is larger, the swapfile
      will grow, otherwise the previous swap file parameters are
      used.

      Returns:   rtmOK           - Successful
                 rtmNoMemory     - Not enough disk space
                 rtmFileIOError  - Could not open/grow file
   }


 function MemCloseSwapFile(var Delete: Integer): Integer;
   {  Closes the swapfile if it was created by the current task.
      If the value returned in "Delete" is non-zero, the swapfile
      was deleted.

      Returns:   rtmOK           - Successful
                 rtmNoMemory     - Not enough physical memory to run
                                   without the swap file
                 rtmFileIOError  - Could not close/delete the file
   }

 implementation

   function MemInitSwapFile;  external 'RTM' index 35;
   function MemCloseSwapFile; external 'RTM' index 36;

 end.




--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/05  21:57:51

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-04-93 08:35:00
From       Dj Murdoch
To         Aaron Marasco
Subject    Re: LONGINT SUBTRACTION

  AM>  On 12-28-92 DJ MURDOCH wrote to AARON MARASCO...
 DM>         TIMENOW := longint(HoursZ)*3600 + longint(MinutesZ)*60 +
 DM> SecondsZ;
 AM> Thanks. I didn't realize that longint is a function. It's not
 AM> listed in TP6 Run-Time Library book. However, it does work!
 AM> Thanks a real lot!

It's not really a function, but TP allows you to use it as one.  Here I'm
using it for an explicit type conversion.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/05  21:57:51

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-04-93 08:38:00
From       Dj Murdoch
To         Goran Eriksson
Subject    Re: DPMI and int vectors

  GE> Is there any documentation out there on how I could
 GE> execute privileged instructions from my Borland Pascal
 GE> protected mode application?

I think generic DPMI documentation is all I've seen.  You're not allowed to
execute the privileged instructions yourself, but the DPMI server will provide
all the safe services for you.  I forget where the official DPMI docs come
from , but you can look in a generic manual like Ralf Brown's PC Interrupts
book (or his interrupt list), or Ray Duncan's Extending DOS.

 GE> But that seems to get me something in x that isn't the
 GE> correct physical IDTR base address. The interrupt table
 GE> limit in x[1] seems ok though (2047). What is the correct
 GE> syntax for getting that information?

 GE> By the way. According to my sources the IDTR base address
 GE> is 24 bits in the 80286. I don't have the the Intel 80386
 GE> Programmer's Reference Manual at home so I cannot check,
 GE> but I could well believe that that address has been
 GE> extended to 32 bits in the '386. Considering that the DPMI
 GE> environment seems to be built on the '286 architecture,
 GE> would it be correct by me to assume that in a BP protected
 GE> mode application only 24 bits should be used? Even when
 GE> running on a '386 or '486?

 Sorry, I've never played around with those things.  I don't know.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/05  21:57:52

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-04-93 08:43:00
From       Dj Murdoch
To         Goran Eriksson
Subject    Re: DPMI base addresses

  GE> Doing some experiments of my own I find that it could well
 GE> be that the segment descriptor bit is included in the
 GE> GetSelectorBase function result. Also I find that
 GE> inconsistent with the GetSelectorBase description in the Language Guide.

 GE> Is there any more detailed (and maybe accurate)
 GE> documentation elsewhere? In the Borland Open Architecture
 GE> Handbook or in the Windows API Reference?

I don't have either of those so I couldn't tell you.  BTW, where did you find
GetSelectorBase described?  All I can see is one line; did you find more than that?


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/05  21:57:52

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-04-93 08:47:00
From       Dj Murdoch
To         JEFF GUILLAUME
Subject    Re: Heap overflow!! Argh!

  JG> help with that? <grin>).  Can anyone explain to me what's wrong
 JG> with this?  First of all, let me define my memory settings, types,
 JG> etc....

 JG> {$M 60000,0,655350}

 JG> Type
 JG>   CallsToday = Record
 JG>                  CallerNum   : LongInt;    {* Caller number of caller *}

 JG>                  Name        : String;     {* Name of caller *}
 JG>                  UserNum     : String;     {* User number of caller *}
 JG>                  TimeCalled  : String;     {* Time they called *}
 JG>                  DateCalled  : String;     {* Date they called *}
 JG>                  Baud        : String;     {* Baud rate *}
 JG>                End;

That record takes up 1284 bytes (or so).  You could make it a lot more efficient
by using shorter strings, or by using PString pointers in the record.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/05  21:57:52

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-05-93 07:52:00
From       Dj Murdoch
To         Joe Jared
Subject    Re: Bug testers wanted

  JJ> Keypressed is broken in TP 6.0, so if it's broken in 7.0
 JJ> I'm not surprised.
 JJ> I initially used keypressed in my sprite engine keyboard
 JJ> handler, but it got confused when the keyboard buffer
 JJ> loaded up, and looped itself to death.

I've never heard of this before - could you tell me how to reproduce it?

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/07  08:51:06

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-05-93 07:56:00
From       Dj Murdoch
To         Ron Allred
Subject    Re: TEMC.EXE

  RA>     Does anybody know what this file does?  I just noticed
 RA> it in my turbo directory.

It's the macro compiler; I don't think it's described in the manual in TP
6 or BP 7, but is documented in TEMC.DOC.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/07  08:51:06

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-05-93 08:02:00
From       Dj Murdoch
To         Howard Hamlin
Subject    Re: Protected Mode IDE pr

  HH> This is NOT a hardware problem for several reasons : Too many of us are
 HH> experiencing this problem only when using Borland's DPMI interface.  I've

 HH> never had this problem with my PC before.  I have a plain-vanilla 286 (DOS

 HH> 3.2, no TSR's, no QEMM/386 MAX) and I'm having the
 HH> problem.  So, all things
 HH> considered, I have to blame the DPMI.

Borland's DPMI server may be the only protected mode program you've run, or
may be unique in some other way.  Just because it's the only program you've
found that has trouble on your machine isn't strong evidence that there's
anything wrong with it.

Borland *does* have a history of writing programs that test the system more
than others; witness all the problems people had with buggy mouse drivers
under TP 6.  This has both positive and negative aspects:  it means they can
get more performance out of very stable systems, but are likely to push flaky
ones over the edge.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/07  08:51:06

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-05-93 20:18:00
From       Terry Hughes
To         John Reid
Subject    Data-Base ToolBox 4.0 bu


JR> BTW, the separate sort routine is still very useful. It is a nonrecursive
JR> quicksort that (unlike Turbo Power's similar unit) automatically goes to

JR> disk when it runs out of heap. It is fast and real easy to use to sort
JR> anything.

You seem to be implying that our MSORT doesn't automatically go to disk
when it runs out of heap space. That's not true.

If all items fit in memory then MSORT does an in-memory non-recursive
quicksort. If all items don't fit in memory then it will start writing
out merge buffers to either disk or EMS. And MSORT works in real mode,
protected mode and Windows; plus it can be up to several times faster
than Turbo Access's sort (depending on the sort parameters).

Oh wait ... maybe you were referring to the sort routines provided by
TPRO and OPRO? In that case you are correct; they were designed for
simple in-memory sorts only. I wouldn't try to compare those sort units
with the one's in Turbo Access; each was designed with a different
objective in mind.

-Terry
___
 X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss/286 v1.02a on 93/01/07  08:51:26

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-05-93 21:05:00
From       Dj Murdoch
To         Tim Evans
Subject    Streams (was Typed Files.)

  TE> Could you give us a short tutorial on how to use streams?
 TE> I've been playing around with them, but am having a hard
 TE> time understanding it. What are the advantages to using them?

Sure, I'll give a quick tutorial.   I'll assume you want to use them as a
substitute for typed files or for untyped files using BlockRead/BlockWrite.
 That's what the manual misses.  It gives quite a good discussion of how to
use objects with them, so I won't talk about that.

So here goes:

Let's say you have a big database that's made up of all the same kind of record, say


  type
    Tdatarec = record
      name : string[40];
      address1 : string[80];
      address2 : string[80];
      address3 : string[80];
    end;

Then a fairly natural standard Pascal way to store this is in a "file of Tdatare
".  This would be a binary file; it would contain multiple copies of these
records, at 41 + 3*81 = 284 bytes each.

However, this is a pretty inefficient way to store a record like this if all
you want is sequential access.  The reason is that most names won't use a
full 40 characters, and most addresses won't be a full 3 lines of 80 characters.
 You're probably storing a lot of junk at the end of each string that's not
needed (and can even be a security problem:  someone could look at the junk
in a binary file viewer, and see whatever was sitting in that spot in memory
before you loaded your program).

A more efficient way to store this record is just to store as much of each
string as you actually use.  If length(name) = 10, then store 1 byte containing
the length, and 10 bytes of name, for a saving of 29 characters.  Same for
the address lines.

The trouble is that standard Pascal provides no support for this kind of thing.
 Typed files have to consist of elements that are all of a fixed size; variable
sized records aren't allowed.  Before they introduced objects, Borland worked
around this by introducing the untyped file.  It's essentially just a stream
of bytes (or some other fixed record size), which you can read by specifying
the number of bytes you want to read each time.

To read one of the records above, you'd do something like this:

  procedure ReadRec(var f:file; var DataRec: TDataRec);
  begin
    with DataRec do
    begin
      blockread(f,DataRec.name[0],1);
      blockread(f,DataRec.name[1], length(name));
      { etc. for address1, address2, address3 }
    end;
  end;

var
  f : file;
  datarec : TDatarec; begin
  assign(f,'filename.dat');
  reset(f,1);
  ReadRec(f, Datarec);
  { etc. }
  Close(f);

 This is treating your data file as a stream of bytes, and doing slightly
lower level I/O than a typed file does.  If you're happy with this, then you
already know how to use Streams.

There are a few problems with the Blockread approach.  First, one of the most
common errors in using untyped files is to Reset them improperly:  you need
to say
   Reset(f,1);
*not*
   Reset(f);
or you end up with a record size of 128 bytes, and wipe out all kinds of things
in memory when the attempt to read the name doesn't just read length(name)
bytes, but reads 128*length(name) bytes.

The second big problem with BlockRead is also associated with the Reset.
Reset doesn't let you specify whether you want read-only or read-write access.

 You need to fiddle with the System unit's FileMode variable to control that.
 This is probably the most common error in using BlockRead; programs that
only need to read a file will open it in the default read-write mode, and
bomb when the file has been declared read-only.  (Just noticed that I forgot
it in my sample:  I should have put FileMode := 0 before the Reset.)

The final problem with BlockRead is speed.  If you fill out my ReadRec procedure
to read all 4 fields, you'll find that it's calling DOS 8 separate times to
read data from the disk.  DOS does some buffering, and a disk cache helps,
but this is still much slower than doing it all in a single read.  This means
that people using BlockRead usually read a big block into a buffer, and then
dissect the buffer themselves.

All of this is much simpler if you use Streams.   The program fragment above
would look like this:

  procedure ReadRec(S:PStream;var DataRec:TDataRec);
  begin
    with DataRec do
    begin
      S^.Read(name[0],1);
      S^.Read(name[1],length(name));
      { etc. for address1, address2, address3 }
    end;
  end;

var
  S : PStream;
  datarec : TDatarec; begin
  S := New(PBufStream, init('filename.dat',stOpenRead,2048));
  { This opens the stream in read-only mode with a 2048 byte buffer. }
  ReadRec(S, Datarec);
  { etc. }
  Dispose(S,done);

The real advantage comes when you want to make a change.  If it turns out
that the buffer isn't necessary, you just change one line:

  S := New(PDOSStream, init('filename.dat',stOpenRead));
  This opens the file without buffering, and is almost identical to using
BlockRead.  Or if you find that a buffered file isn't fast enough, you can
easily copy the whole file into memory (using a TMemoryStream in TP 7, or
a TEMSStream in TP 6, or lots of different specialized streams that you could
write yourself).  The way you set up your file will be different, but the
way to read from it will be identical.

There are some negatives with streams, but this message is long enough that
I won't discuss them.  Just a quick list:

In the original release of TP 6.00, the TBufStream had a bug that showed up
if you mixed Seek and Write; if you swap the parameters stOpenRead and 2048
in your TBufStream.Init call, you can cause really bizarre behaviour; if you
specify the wrong size for a read, you can get very confused.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/07  20:52:16

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 08:03:00
From       Dj Murdoch
To         Aaron Marasco
Subject    Re: LONGINT SUBTRACTION

  AM> It still doesn't work though. The LongInt function works, but I
 AM> still cannot subtract the two longints?!?!
 AM>
 AM> FUNCTION ELAPSEDTIME(VAR timername: TIMERTYPE): LONGINT;
 AM> VAR
 AM>    TDiffZ : LONGINT;
 AM> BEGIN
 AM>    TDiffZ := ( Timername[2] - Timername[1] ) ; {what is
 AM> the problem here?}

There's probably something wrong with your declaration of TIMERTYPE.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/07  20:52:16

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 20:58:00
From       Dj Murdoch
To         Jud Mccranie
Subject    Re: BP 7 bug list

  DM> Tab is for navigation, not selection.  For more detail, see one
 DM> of my earlier messages explaining this to you.

 JM> I know that, but you're still missing the point.  Tab navigates,
 JM> cursor keys highlight, and RETURN selects the highlighted item,
 JM> EXCEPT if you are selecting the primary file and have not pressed
 JM> any cursor control keys.

No.  RETURN only selects the highlighted item when it happens to agree with
the input line.  RETURN selects the input line.

 JM> Compare the way New works to selecting Primary.  New works correctly.

I don't know what you're talking about.  File New doesn't give you a file
dialog.

Let's just give up on this one, okay?  I'm not particularly interested in
bugs that have no effect on the output of the compiler.  If you don't like
the way it works, complain to Borland.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:11:57

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 21:04:00
From       Dj Murdoch
To         Jud Mccranie
Subject    Re: bug testers wanted

  JM> I tried the test on my system, since I'm prone to wierd lockups,
 JM> etc, but it ran OK.  I'll try it on a 486 running Lantastic and
 JM> see what happens.

Thanks.  If you want to try out the full detector, I sent it out as TRASH.ZIP
on PDN a few days ago.  I never did hear from anyone who had the bug on their
own, so I had to make a buggy TSR to try it on.  I hope it works in the real
case, too.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:11:57

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-04-93 12:56:00
From       Mark Ouellet
To         Canadian Bp 7.0 Users!!!!!!!!!
Subject    VERY IMPORTANT, PLEASE READ THIS!!!!!


Hi Canadians,

    If you are planning on buying OPEN ARCHITECTURE for BP 7.0. It is
not yet available from Borland Canada!!!!

I ordered it and got the C++ version!!!

The Pascal version is available from Borland USA.

    If you call Borland Canada to order this, make sure you ask them to
confirm it is the PASCAL version and tell them you know a pascal version
is available from Borland USA (They have no clue as to wether or not a
Pascal version is comming to Canada, so they might think the C++ version
is the only one). Since I now told them there was a Pascal version
available from Borland USA, they might move a bit faster to get it
available here.

So they might have it when *YOU* call to order, just make sure of it.

    If like me you got the wrong version from Borland Canada, you can
call them to get a return number and send them the product, COLLECT!!!

    Borland USA will also accept Canadian orders of Open Architecture
for Pascal. That's where I ordered my new copy.

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 01:50:00
From       Mark Ouellet
To         Mike Copeland
Subject    Re: backspace


    On 02-Jan-93, you, Mike Copeland, of 1:114/18.10 wrote...

 MC> Not really.  In other messages I've posted, I show _all_ of what I
 MC> do, which is:
 MC>
 MC> if Length(S) > 0 then Dec(S[0]);
 MC>
 MC> The particular message I was replying to had a very convoluted way of
 MC> decrementing the length (regardless of the string length), and I was
 MC> merely showing a simpler way of doing it. I learned long ago to assure
 MC> the valid length of the string before reducing it...  8<}}

Well Mike,
    In that case it probably would have been better to show the full
code. One more line doesn't make much of a difference for echomail but
it can make a world of difference to new users who missed your first
post and are unaware you first checked the length.

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 01:52:00
From       Mark Ouellet
To         Andres Cvitkovich
Subject    Re: Checking file types


    On 28-Nov-92, you, Andres Cvitkovich, of 2:310/36.9 wrote...

 AC> PrintableFile := TRUE; if ext[0] = #3 then
 >>  TC>        PrintableFile := (pos(ext,'.OBJ.COM.EXE') = 0);

 AC> Maybe TeeCee would write it this way if he thinks it over. Should work
 AC> perfectly, then (though untested) :-)

Andres,
    implest fix I have seen so far, congratulations!!!

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 01:56:00
From       Mark Ouellet
To         Andres Cvitkovich
Subject    Re: Speed wanted !


    On 28-Nov-92, you, Andres Cvitkovich, of 2:310/36.9 wrote...

 AC> Hi Mark (again),

    Well hi Again Andres

 >>     Actually, 64K or 65536 bytes or array [0..65535]
 >> of byte IS the largest allowed.
 AC> if you'd have tried, you'd see that array[1..65535] is the largest
 AC> possible array (tested!) though not recommendable.

    I Stand corrected, I just tried it and you are right. Wether it is
declared as a type or directly in a cariable definition 65535 bytes is
the maximum. Thanks for pointing that out!!

 >>     65520 is the largest data structure SAFE to use. The reason is that
 >> offsets will vary from 0 to F in normalized pointers.

 AC> in TP6, offsets will be 0 or 8 only since Heap is allocated in 8-byte
 AC> blocks (that's a tribute to the object-oriented programming,
 AC> especially Turbo Vision), and if the byte array is the only var, you
 AC> can be rather sure it's offset is 0.

Yes Andres,
    I had seen reference to the effect that 65528 was safe to use.
Apparently someone came to that conclusion through some testing. I
decided to stay on the safe side though as I beleive 65520 is safe to
use from TP 4.0 to TP 7.0.

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: The Sequel to Cramer VS Cramer: TPCramer VS UUencode ;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 14:16:00
From       Mark Ouellet
To         Francois Thunus
Subject    Re: TCSEL003: ReadTxt


    On 31-Dec-92, you, Francois Thunus, of 2:270/25.1 wrote...

 FT> Nothing fancy, as you can see. However, when i try to read a text
 FT> with more than 254 lines, it freezes even thought i still have more
 FT> than 500k available (using the line command compiler-nothing else but
 FT> my program in memory. the program part is 57 k and the data part 42k,
 FT> reported by tpc after compiling). The compiler directive for memory
 FT> are heap 5076, min stack 65530 max stack 655300. I have tried various
 FT> min stack and heap size from 0 to the maximum possible.

Francois,
You could use the following unit provided to Pascal echo readers by
Wilbert Van.Leijen:

Unit TextUtil;
{    Written by Wilbert Van.Leijen and posted in the Pascal Echo }

Interface

Function TextFilePos(Var f : Text) : LongInt;
Function TextFileSize(Var f : Text) : LongInt;
Procedure TextSeek(Var f : Text; n : LongInt);

Implementation
uses Dos;

{$R-,S- }

Procedure GetFileMode; Assembler;

ASM
                CLC
                CMP    ES:[DI].TextRec.Mode, fmInput
                JE     @1
                MOV    [InOutRes], 104         { 'File not opened for reading' }
                XOR    AX, AX                  { Zero out function result }
                XOR    DX, DX
                STC
@1:
end;  { GetFileMode }

Function TextFilePos(Var f : Text) : LongInt; Assembler;

ASM
        LES    DI, f
        CALL   GetFileMode
        JC     @1

        XOR    CX, CX                  { Get position of file pointer }
        XOR    DX, DX
        MOV    BX, ES:[DI].TextRec.handle
        MOV    AX, 4201h
        INT    21h                     { offset := offset-BufEnd+BufPos }
                XOR    BX, BX
        SUB    AX, ES:[DI].TextRec.BufEnd
        SBB    DX, BX
        ADD    AX, ES:[DI].TextRec.BufPos
        ADC    DX, BX
@1:
end;  { TextFilePos }


Function TextFileSize(Var f : Text) : LongInt; Assembler;

ASM
                LES    DI, f
                CALL   GetFileMode
                JC     @1

                XOR    CX, CX                  { Get position of file pointer }
        XOR    DX, DX
        MOV    BX, ES:[DI].TextRec.handle
        MOV    AX, 4201h
                INT    21h
        PUSH   DX                      { Save current offset on the stack }

                PUSH   AX
        XOR    DX, DX                  { Move file pointer to EOF }
        MOV    AX, 4202h
        INT    21h
        POP    SI
        POP    CX
                PUSH   DX                      { Save EOF position }
        PUSH   AX
        MOV    DX, SI                  { Restore old offset }
        MOV    AX, 4200h
        INT    21h
        POP    AX                      { Return result}
        POP    DX
@1:
end;  { TextFileSize }

Procedure TextSeek(Var f : Text; n : LongInt); Assembler;

ASM
        LES    DI, f
                CALL   GetFileMode
        JC     @2

        MOV    CX, Word Ptr n+2        { Move file pointer }
        MOV    DX, Word Ptr n
        MOV    BX, ES:[DI].TextRec.Handle
                MOV    AX, 4200h
                INT    21h
                JNC    @1                      { Carry flag = reading past EOF }
                MOV    [InOutRes], AX
                JMP    @2
                                                                             { Force read next time }
@1:     MOV    AX, ES:[DI].TextRec.BufEnd
                MOV    ES:[DI].TextRec.BufPos, AX
@2:
end;  { TextSeek }
end.  { TextUtil }

    With the aid of that unit you could save the position of each line
in the text file to an array of Longint as you read them. You can also
open a temporary file, a file of longint, where each record would simply
represent the offset of that line in the text file. If you need to go
back in the text, simply read the offset of the line where you which to
restart reading. Suppose you are on line 391 and you decide to go back
say, 100 lines, simply do a Seek(MyIndex, CurrentLine-100). Then use the
TextSeek procedure to seek to that position in the text file and start
reading again, taking into acount that you allready read those lines so
you either re-write the offsets to your index file, which won't hurt
since you will just be overwriting the records with the same values
again or simply skip writing the offsets until you reach a point where
NEW lines that haven't yet been read are reached. Save any new offset as
you read forward.

    With this method you can go back-wards as well as forwards. In fact
if you first read the file, saving all offsets until the end, you can
offer the user to seek to any line number.

    When you read new lines or seek backwards, simply flush any lines
from memory. Or maybe you could decide to keep a predetermined number of
lines in memory say 300. When ever the user asks to read forward or
backwards, simply flush the 100 first or Last line, depending on the
direction the user wants to go, and read 100 new lines from the text
file.

    Maybe the best approach to be sure of sufficient memory is to
determine how many lines will fit. Suppose you limit line lengths to 255
caracters. Determine how many will fit in a worse case scenario. Create
as many 255 caracter strings as will fit. Divide that number of lines by
4. Say you managed to create 1000 strings of 255 caracters. Divided by 4
is 250. So set a limit to 750 strings to be safe and make any disk
accesses in bundles of 250 Lines.

    You can also keep the line offsets in memory in arrays but you will
be limited to 65520 / 8 = 16380 lines. Make that two arrays stored on
the heap and you've got yourself enough space to store 32760 line
offsets which at 255 caracters by line would be an 8.3 Meg file.

Hope this helps.

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 14:51:00
From       Mark Ouellet
To         Preston Garrison
Subject    Re: Hmm


    On 31-Dec-92, you, Preston Garrison, of 1:150/320.0 wrote...

 PG> Could someone please explane to me why XX or other type of encoded
 PG> messages aren't allowed?? What is the differents between sending
 PG> someone  your source to you program or someone sending and XX version
 PG> of this  source in LZH format, besides the obvious THE XX VERSION IS
 PG> MORE THEN  HALF THE SIZE!!!!!!!!

Preston,
    The main reason is that since XX can work on binary files such as
ZIPs ARjs etc... there is no way to garrantee that ONLY Source will be
sent this way. .TPU's are of no help to users who read this echo to
learn. Source is usefull though. Also an XX encoded message, even if it
contains source is not directly readable. I intend to include decoders
to most common encoders used in fidonet when I finally start programming
my offline reader but that won't be for some time. So those messages are
not readable as they are and one can't know if they need it until they
extract them.

    The main reason for this echo though has allways been to provide
knowledge and help and as such Source code is the only allowable form.
because of that, TeeCee once wrote TPCrammer, which was a tokenizer that
compressed Pascal Source files enough to be posted by replacing ONLY
Tokens and Reserved keywords such as BEGIN, END etc.. with a Token
number. It was soon droped because the readability was still missing.

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 15:08:00
From       Mark Ouellet
To         Dj Murdoch
Subject    Re: Windows API Call


    On 01-Jan-93, you, Dj Murdoch, of 1:249/99.5 wrote...

 MO>>>     Pascal can't be told to use C convention.

 DM>> Why couldn't Pascal use the C convention?

 MO>>     Have you seen a keyword to tell TP to use C parameter-passing
 MO>> convention??? I know I haven't but if you got a scoop then go ahead!

 DM> Sorry, I thought you were talking in general.  No, TP is completely
 DM> inflexible.  Other Pascals aren't; e.g. SBP+ is supposed to be quite
 DM> flexible about calling convention.

Dj,
    The error is partly mine, I should have said "Turbo Pascal"!!! So
I'll take half of your apology if you'll take half of mine ;-)

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 15:17:00
From       Mark Ouellet
To         Håkan Johansson /Under Utblidn
Subject    Re: DPMI


    On 31-Dec-92, you, Håkan Johansson /Under Utblidning, of 2:201/602.
0 wrote..

 DM>> I don't think they need to be in fixed segments.  They use the same

 DM>> call mechanism as virtual methods for objects, and those certainly
 DM>> don't need to be in fixed segments.

 HJ> Rereading chapter 17 in the Language guide I "saw" the following two
 HJ> sentences on page 195-196: "For example, by simply updating the base
 HJ> address field of a segment's descriptor, the operating system can move
 HJ> a segment around in physical memory without affecting the application
 HJ> that uses the segment. The application refers to the segment's
 HJ> selector only, and the selector isn't affected by changes to the
 HJ> descriptor." I guess it answer the question. But why then do interrupt
 HJ> handlers need to reside in fixed segments? After all, the interrupt
 HJ> enable flag is cleared during a memory move, isn't it? Then again,
 HJ> perhaps the addresses of the interrupt handlers aren't stored in low
 HJ> memory as in real mode. But must they not be? I guess I'm rather
 HJ> confused about this! :-) /Haakan J.

Håkan,
    because if they are not stored in FIXED segment then the operating
system could move the code around. Which means, the interrupt adress
would point to a zone of memory where your interrupt routine USED TO
BE!! OUCH!!! You can easily imagine what would happen on the next
interrupt.

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 15:49:00
From       Mark Ouellet
To         Boxo D Clown
Subject    Re: Troi


    On 12-Nov-92, you, Boxo D Clown, of 51:808/50.0 wrote...

 BD> Ugh.  Are these appropriate in here.

    NO!!! They Aren't, nor are the other dozen or so that have been sent
allready!!

    This is the Pascal echo, Trevor Carlsen was/is the moderator until
?? can't remember what date.. At which time Duncan J Murdoch will be
taking over Trevor's responsability to the end of the normal term. At
which time I guess we'll have another election.

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-06-93 15:56:00
From       Mark Ouellet
To         Dj Murdoch
Subject    Re: Turbo Vision


    On 01-Jan-93, you, Dj Murdoch, of 1:249/99.5 wrote...

 BC>>     For one thing, join us at TURBOVISION. It is an echo
 BC>> made especially for discussing Turbo Vision.

 DM> I don't think TV is off-topic here, but if you want to advertise the
 DM> TV echo, shouldn't you say how to hook up?  Or is it on the backbone
 DM> now?

Dj,
    He didn't say it was offtopic but the guy clearly needs more help
than he will get here. He needs the basics... ALL OF THEM!! ;-) He
obviously hasn't read his book so he'll need all the help he can get and
the TurboVision echo is the best place for that.

        Best regards,
        Mark Ouellet.


--- Squish v1.01
 * Origin: Sequel to Cramer VS Cramer: TPCramer VS UUencode;-) (1:240/20.4)
 * Tossed by SFToss/286 v1.02a on 93/01/08  11:12:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-08-93 20:05:00
From       Trevor Carlsen
To         All
Subject    My resignation as moderator.



Thanks to all those who have posted such ego-boosting echomail and netmail
messages to me. It is most gratifying.

As there are far too many messages to respond individually and as so many
have asked questions in netmail, here is the background to my decision...

1. I have sold my programming and consultancy business.
2. I have bought a supermarket in another town (1050kms away).
3. I take it over on March 1.
4. I will be "off-air" for up to a month at around that time.
5. I will continue to promote the current contest.
6. With DJM's permission, I have ideas for other contests.

P L E A S E  if you wish to comment on this, do it by  netmail only.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 93/01/09  00:39:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-07-93 19:14:00
From       Dj Murdoch
To         All
Subject    Open Arch. description of help files

 This is for anyone who has bought the BP 7 edition of the Open Architecture
book.

The BC++ edition describes the binary format of the .TCH/.TPH help files,
but leaves something out:  the Text Records appear to be terminated with a
^A (#1) character, but this isn't mentioned.  The .C program to decompile
the help file ignores this character.

Does the BP version of the book talk about this?  Can I count on it appearing
only at the end of a text record, or could one be embedded within the record?

Thanks in advance for any help.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/09  00:39:19

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-07-93 19:25:00
From       Dj Murdoch
To         Mark Ouellet
Subject    Re: Turbo Vision

  MO>     He didn't say it was offtopic but the guy clearly needs more help
 MO> than he will get here. He needs the basics... ALL OF THEM!! ;-) He
 MO> obviously hasn't read his book so he'll need all the help he can get and

 MO> the TurboVision echo is the best place for that.

It's not on the backbone yet; how does someone get hold of it?

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/09  00:39:19

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-07-93 19:28:00
From       Dj Murdoch
To         Mark Ouellet
Subject    Re: Troi

  MO>     This is the Pascal echo, Trevor Carlsen was/is the moderator until
 MO> ?? can't remember what date.. At which time Duncan J Murdoch will be
 MO> taking over Trevor's responsability to the end of the normal term. At
 MO> which time I guess we'll have another election.

I won't be taking over until Feb 1, and only then if TC doesn't change his
mind.  There isn't any "normal term" or provision for an election for the
position unless the moderator calls one (or disappears and someone else calls
one).

This is in the rules that TC posts monthly.  I'm not planning any changes.
 The moderator is a constitutional monarch, not a president :-).

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/09  00:39:19

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-07-93 19:45:00
From       Dj Murdoch
To         Chris Priede
Subject    Re: Simple TSR wanted

  CP>         It is rather hard to believe software could trash registers n
 CP> times per second and go unnoticed until a new version of TP arrives.


This was one of the many things that delayed the release of PKZIP 2 for so
long.  There really is sloppy software out there that trashes the 386 registers.
 Not much any more; my call for testers only found one person who had actually
observed the problem.  This was on a Novell non-dedicated file server, whatever
that is.

 CP> It
 CP> should have broken MANY other programs by now and fixed long ago. I'm
 CP> only guessing, but it is more likely TP runtime library expects values
 CP> to remain in extended registers for too long, in other words, after
 CP> calling some software interrupt. However, you are right, there is little
 CP> reason to call software interrupts during longint calculation.

In fact, the RTL source code comes with BP so this is easy to check - it doesn't
call any software interrupts during longint calculations.

 CP>         Anyway, if the problem is a hardware interrupt, then it is most
 CP> likely one of two timers: int 08h or 70h (AT real time clock). Could
 CP> also be something used by a network adapter, if there is one installed.
 CP> Nothing else occurs regularily enough, all other interrupts are executed
 CP> only if there is some activity on connected device (serial port, disk,
 CP> keyboard, etc.).

I don't think this is safe reasoning.  If another hardware interrupt is bad,
it could still cause trouble even if it doesn't happen frequently.  It just
wouldn't cause so much trouble, so it would be harder to diagnose.

Try to save and restore all registers before calling
 CP> the original interrupt handler. Something like this should do:

 CP> .386

 CP> OldInt08        DD      ?

 CP> NewInt08        PROC    FAR
 CP>                 pushfd          ;save extended flags
 CP>                 pushad          ;save extended registers
 CP>                 pushf
 CP>                 call    cs:[OldInt08]   ;saved interrupt vect. in code seg


I thought of doing it this way, but decided on a more involved method.  There
are several problems with this fix:
  - it adds 42 bytes to the stack usage of the hardware interrupt;
  - it fails to protect FS and GS (which aren't used by TP, but might be used
by some assembly code);
  - it would badly mess up a software interrupt that was expecting to return
information in the 8086 registers or flags.  I can't imagine why anyone would
put one of those on one of the hardware interrupts, but someone might.

The solution I came up with is a little bit slower, a little bit less complete
(I forgot about the extended flags), quite a bit bigger, but it uses only
about 26 bytes of stack space and solves the other two problems above.

Here's my general purpose ISR:

 const
  { These constants allow us to code 386-specific instructions }
  Op32   = $66;
  PushFS = $A00F;
  PushGS = $A80F;
  PopFS  = $A10F;
  PopGS  = $A90F;

 procedure FixupISR; far; assembler;
 { This ISR saves and restores the high word of EAX,EBX,ECX,EDX,ESI, and EDI,
   plus FS and GS. Use it to fix up a bad handler.  Uses 26 bytes of stack

   space. }
 asm
  push bp
  mov bp,sp

  db Op32; push ax
  pop ax
  db Op32; push bx
  pop bx
  db Op32; push cx
  pop cx
  db Op32; push dx
  pop dx
  db Op32; push si
  pop si
  db Op32; push di
  pop di
  db Op32; push bp
  pop bp
  dw PushFS
  dw PushGS
  push word ptr [bp+6]           { old flags }
  mov bp,[bp]                    { and restore BP }
  call dword ptr cs:InterruptRecs[PtrOfs]
  push ax
  pushf
  pop ax                     { Now flags are in AX }

  push bp                    { Save the ISR's BP }
  mov bp,sp                  { Set up our frame again }
  add bp,22
  mov word ptr [bp+6],ax      { This way flags on our return will be
                                   as the old ISR returned them. }
  pop ax
  mov word ptr [bp],ax        { as will BP }

  pop ax
  dw PopGS
  dw PopFS
  push bp
  db Op32; pop bp
  push di
  db Op32; pop di
  push si
  db Op32; pop si
  push dx
  db Op32; pop dx
  push cx
  db Op32; pop cx
  push bx
  db Op32; pop bx
  push ax
  db Op32; pop ax

  pop bp
  iret
 end;

 CP>         Install an interrupt handler like this on both timer interrupts
 CP> and any other interrupts you suspect. The old interrupt vector variable
 CP> should be in code segment, so we can access it without loading a segment
 CP> register. If it helps, then you will know which interrupt is guilty and
 CP> all you have to do is trace through the interrupt handler.

A longer version of my code checked the returned values of all the registers
against the saved values, and recorded instances where they were changed.
 If you want to see that, look for TRASH.ZIP.  I sent it out on PDN a few
days ago, and it's also available on Internet from garbo.uwasa.fi:/pc/turbopas.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/09  00:39:19

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-07-93 07:48:00
From       Dj Murdoch
To         Jason Huebel
Subject    Re: Typed Files.

  DM> FillChar(myrec,sizeof(myrec),0);

 JH> I've found that isn't really necessary. I could be wrong,
 JH> but you don't need
 JH> to initialize the variables since it saves the length byte in the file. Is

 JH> that true? I mean, from what I've worked on so far in TP
 JH> and typed files, it's
 JH> worked for me so far.

It depends what you mean by "necessary".  If your aim is to make the string
readable, then you don't need to bother.  If you're worried that the junk
at the end of the string might contain sensitive information (a decrypted
password, for instance) because it happened to be sitting in memory at just
the right place, then you'll want to clear out the junk.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/09  00:39:37

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-07-93 07:56:00
From       Dj Murdoch
To         Mark Mckay
Subject    Re: tp7/bp7 bugs

  MM> Problem:  Keyboard useless in TPX.EXE IDE when mixing
 MM> mouse and keyboard           commands.

Thanks for sending the report.  I'd suspect your mouse driver; is there any
chance you could try a different version?


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 93/01/09  00:39:38